Quote from Marty_Deslions :

I must admit that the prolonged silence has left me a bit concerned.

I'll start by linking to a couple of threads which show a lot of the work I have been doing recently:

Test Patch D33: https://www.lfs.net/forum/thread/102117
Editor Test Patch D40: https://www.lfs.net/forum/thread/102626

As you can see, particularly on the Editor Test Patch thread, I have made a huge number of improvements for the mod support. I find it a great thing that LFS is a way for people to be creative, and the mods system is a massive new part of that. It was very "new" indeed when released (basically a bunch of dev editors brushed up a bit) which is why there have been so many issues to sort out.

In the past months, while I have been doing these, Eric was at first finishing South City, which took a lot longer than he anticipated. Filling those holes is not easy, and he likes to fill them just as people would actually "fill the holes" when building a real city. I received an update recently and tested it, reported a bunch of issues and he fixed those. We find the completion level very good now, basically good enough for public testing when we can get the full version together. He is now working on the Kyoto improvements. As you may know from the official progress reports, that was never finished before Eric moved onto the South City, that turned into an epic development and massive expansion.

On my side, I'm trying to finish test patch things so that I can finally complete the tyre physics. In fact my current focus is on wheels, both in the development and public version. In the public version there should be a graphical update for wheels in the next few days, to go along with the many updates there have been for mods. Again, please read the test patch threads to know what I'm talking about.

There is also other work I do, that you never see, such as updates for the track editor. Suppose Eric is doing a task and finds he has to do something in a laborious or repetitive way and one of us thinks of a new editor function that could help him achieve certain tasks more quickly, then I always want to stop whatever else I was doing and work on the track editor for a few days.

I'm trying to get to an official release so my focus can then be entirely on the tyre physics in the development version. It has taken me much longer than expected to complete this round of test patches as there were so many unfinished things in the mods system. When I see creators, working hard and having to use workarounds for issues, I feel a great responsibility to get that issue sorted out.

Of course, the priorities I attach to various tasks, will not be the same as someone else's priority. We all have different priorities, so there's not a person in the world who could agree with all my choice of tasks to work on. But I must work on what I feel is important. Actually I find it a huge mental effort to complete these tasks, and that's why I need to follow the inspiration. Sometimes I'm awake at night working out how to do something, then experimenting and testing, it's a lot of work.

It takes a long time, but there is always progress.

I understand there is a conflict at the boundary between LFS generated tyre/rim and the user created objects. It's something I need to consider. I can't jump to quick fixes. This is because the tyre generation and profile will change a bit in future and existing mods cannot be broken at that point. Maybe LFS needs some defined profile styles for physically plausible rims, including a proper 3D edge between the rim and the tyre, and/or some way to interface cleanly with user defined rims. The current tyre shape is a compromise, designed a long time ago, so I need to examine how the visual tyre and rim width are produced from the "Rim width" setting in the vehicle editor. I realise there is a resolution issue - some mod creators want to use a lot of triangles around the edge to create a perfectly round appearance, but that is not compatible with the tyre resolution as the LFS tyres can move and they are CPU-expensive to send to the graphics card each frame, even in the new LFS system. No doubt there is a better way to do that too, with a special shader.

I do see the issues as I can see the high quality rims that people want to make, so I have to think about this a while. At this point I think the changes are not in the immediate future, as you know I'm trying to do this full release to get back to the tyre physics, so things will be easier when I only have to work on one version of LFS, and we all get the benefit of the new graphics.


Anyway, for today there is a new update, D40.

Vehicle editor:

Hub object custom colours now appear in the list of wheel colours

Modeller:

Reflect object function is now available for individual subobjects
Combined clean object buttons into a single button with a dialog
Spoke mode "export SRE" saves combined spokes as a modeller object
Spoke mode "import SRE" function to load modeller object as a spoke

Download: https://www.lfs.net/forum/thread/102626

Quote from Evolution_R :

I wish the texture was appearing a bit brighter.
In the editor looks fine, but in LFS appears a bit too dark.

I agree, I'm having a look at this to see what sort of results I can come up with, to make the public LFS dashboards have a similar brightness to the ones in the editor, without making older ones excessively bright. I think it's a few hours to carefully figure this out, maybe can release an update tomorrow with better brightness in game.

Quote from Yasso7up :

Are you looking forward to do the same thing to formula and f1 clocks?

I'm not really looking forward to that, no!

I don't have plans to update those clocks at this time. I felt the dial clocks were in serious need of an update for all those reasons. People were forced into either accepting a look they didn't want, or doing workarounds that would not be the proper way to do it. I didn't even plan to do this but sort of fell into it because of the need to add the damage light to the clocks. I don't regret it though, as I'm happy to see what results people can come up with. But it has been surprisingly intense work for the whole of last week and already two days this week.

All I really want to do is get this official update finished so I can leave it and work on the tyre physics. I want to get to the situation where everyone has the new graphics and I can work on one version of LFS instead of copying all the updates into two divergent versions of LFS.

Thanks for the test / demonstration.

One tip for people making custom dashboards:

To protect your mod from future physics changes, in the Speedo settings you should set "Max" to manual. Even if the auto value is OK right now, it's possible that future physics changes will result in a different estimated maximum speed, which could mess up your speedo accuracy.

I think it's less of an issue with the tacho as in that case auto is based on engine setting "Redline" so should not change unexpectedly. Using the manual setting could still help by allowing to you adjust the redline without changing the tacho range.

It's extremely unlikely to be related to the update.

All such times there have been sound and frame rate issues, it has been due to mods with bad sound settings or other issues causing extremes of physics, packet hacks, etc.

We have had cases where such issues were deliberate sabotage, others where it was an innocent mistake, and others due to the low resolution physics not being able to deal with a mod. In no case has it been caused by an LFS update. On the contrary, LFS updates have been released to prevent such issues.

I really have no idea how your exe could be corrupted.

Maybe the issue is reproducible in an MPR. If you could provide an MPR of the server at the trime of the issue, and explain which driver's viewpoint to take, and which time point in the replay, in order to experience the issue, then it should be possible for me to track down the problem. Maybe a good idea to state which server it was on (I guess just a ride?) and what time it was? I guess someone must have an MPR that includes the event?

Last edited by Scawen, Mon, 19 Jun 2023 07:27.

As you may know, I'm trying to finish this round of test patches and release an official version so I can focus fully on tyre physics.

Unfortunately, finishing always takes longer than expected but I'm getting there. One thing to add was the dashboard version of the engine damage light. I did that on Monday, but noticed certain issues with dashboards while I was in the dashboard editor. Remembering various issues and requests for improvement, on Tuesday I started to add options for the tacho (allowing x100, steps of 5, set maximum value) and on Wednesday for the speedo (set maximum value, make mph and km/h have the same needle position). On Thursday I added several options that can be applied to all the dials. Finally today I've added the option to show and position the unit (km/h or mph on speedo, x100 or x1000 on the tacho).

I'm sure many of you will find these options useful and they will add some variety and realism to the traditional style dashboards you set up. I don't suggest that this is complete or allows all the possibilities you would like, but these are the things I could do quickly, in a semi-compatible version.

To see the effect of these options in game, you will need Test Patch D26.

By "semi-compatible" I mean that versions before D26 can still load vehicles you save with this new version, but they won't see the effect of the new options.

Vehicle editor:

Engine damage light can be enabled (in Transmission tab)
Maximum value for main body drag increased from 1.0 to 6.0
Some tooltips added and descriptions adjusted in Aerodynamics tab
Estimated max speed (in Aerodynamics) shows speed in mph or km/h
FIX: Dashboard for electric vehicles was switched off in editor

Dashboard editor:

Speedo:
- set maximum value in km/h (steps of 5)
- option to show units (km/h or mph)

Tacho:
- set maximum value
- x100 or x1000
- gap 1/2 (x1000) or 5/10 (x100)
- options to show units (x100 or x1000)

Options on all gauges:
- needle colour = text colour
- needle is long
- needle above pivot
- hide pivot
- hide numbers
- hide symbol (if applicable)
- hide marks
- smaller text

Download: https://www.lfs.net/forum/thread/102626-Editor-Test-Patch-0-7D34

There are no changes to physics. Maybe on the server you were on, someone applied a handicap. But more likely a psychological, physiological or environmental effect. Our perception and skills vary from one day to the next.

Quote from Flame CZE :

Crashed when trying to enter the modeller from the "new vehicle" screen:

Thanks for the report. This is fixed in D29 which I'll upload in a minute.

Quote from xolan1993 :

Sorry I dont want to seem tone deaf and insult the devs.
Scawen, the way I deal with crash reporting is:

Thank you and don't worry, that is not insulting. I don't pretend to know everything.

I should have a look at a crash handler, though I don't want to spend much time on it now, a good one could save time in the future.

At least to write out exception code, crash address and the module might be nice so people don't have to look in Windows logs. A call stack would be great information too and could solve more cases, especially if the crash is in a commonly used function or in a non-LFS module (called by some function in LFS).

I seem to remember looking at this a bit in the past and it was apparently not easy to obtain a call stack for some reason, or maybe it required a lot of knowledge. Well, I guess that's why you made your own library for it. Anyway, I will read up a little can contact you for more information if I want to do something. Though my priority is to quickly release the new version and get back to the tyre physics.

Interesting thought but it won't be in this round of test patches. Everything I do in the current public version must be merged into the separate development version, which isn't always easy. Also any changes in the core of the physics system are likely to invalidate all the hotlaps, which isn't worth doing at the moment. Also, incompatible setups, online compatibility, interface updates, etc...

I look forward to releasing the development version, so we only have one version and it will be much easier to add new features then.

I just watched this 12 min video about heave springs.
https://www.youtube.com/watch?v=lNInCfCkrkE

Last edited by Scawen, Wed, 10 May 2023 08:01.

Eventually yes, but it's complicated so I don't want to do that in the public version and also the new development version. It will require camera positions and some restrictions (e.g. options for which mirror it replaces, options for multiple camera mirrors). Right now I'm focused on getting the tyre physics finished and won't take on extra difficult tasks.

The LFS developers should host instructions on how to reverse engineer someone's software without their permission?

Honestly, I'm not even sure programs should be allowed to work the way LFS Lazy does, hacking into LFS. But it was allowed in this case, so that is beside the point.

I've added a couple of the most requested features from LFS Lazy into a recent test patch.

I know there are many other features of Lazy that are still wanted, though I assume you would prefer me to to continue working on the new tyre physics, instead of trying to implement the features of LFS Lazy?

It's possible to recreate many of the features of LFS Lazy without resorting to hacking obsolete software which is itself a hack, even if a very good one. I mentioned above, the PACT Driving Assistant which is currently in development has many features that may be of interest (although I don't know which features of LFS Lazy can or cannot be done by PACT).

Last edited by Scawen, Thu, 20 Apr 2023 08:41.

I'm working on it. Progress is not stalled.

I did spend a lot of time last month on test patch and editor updates, but that's not my focus now. I won't go into all the reasons why that happened, but there was an important update, then I saw the E-Challenge, saw something that could be improved there, thought of a few other useful improvements, one thing lead to another...

Not a problem, that's all good. The updates were significant and important.

The idea of the progress reports wasn't really "this is what I will do forever". It was an insight into the development process, and I went into extreme detail, maybe even too personal, so people could really understand what being a programmer is about.

Tyre physics doesn't go the way multithreading goes. For me, it's not really suitable for rapid progress reports. There's a lot of experimentation and testing, research and hard thinking.

However much you want the new version released, multiply that by 100 (rough estimate) and that's how much I want it released. The new version is what I work on and think about for many hours every day. All I can really say at this point is don't worry, I'm on it.

Quote from Aleksandr_124rus :

I have a suggestion (If it's not hard to do) to make visible the tire surface temperature (with tire inner layer temperature) and pressure level with value as it was in earlier versions.

This is really not on topic and has nothing to do with the test patch.

I'm trying to finish the things in the test patch and get back to tyre physics. The test patch thread will not become a random suggestions thread.

Remember the forum section for suggestions: https://www.lfs.net/forum/8-Improvement-Suggestions

Last edited by Scawen, Thu, 23 Mar 2023 10:22.

Quote from FIZ :

While it is important to have a cleanup function that removes all the old versions of a mod, I disagree about an enhancement check based on replays also.

A cleanup function has been added to Test Patch D17. It would be interesting to know how many mods it wants to clean up for you (it offers a button "Delete X of Y mods") and how much the folder size is reduced if you use the function.

Quote from Snoop.DriftEra :

LFS Editor suggestions only thread, LFS Modeller suggestions only thread, LFS Mod system suggestions tread. Confusing...... Is it the right place?

It may be confusing for you, but try to imagine how confusing it is for me, dealing with suggestions all over the place. It's simply helpful and more likely to end up with me doing something, if the request or report is in the right place.

I guess it can't really be so hard to understand? There are only two separate suggestions threads in this forum section. The modeller is where you create a 3D object (points, triangles, mappings). Everything else (vehicle editor, website, mods in game, etc) is not the modeller. It's easier for me to track if you separated your requests into two separate posts, one for the mods system in general, and separately for the modeller.

You see, I can usually update the modeller without any compatibility problems. For example I add a new way to select triangles or a hotkey. There is no compatibility problem. But adding a new kind of suspension physics in the vehicle editor, this is impossible without new versions released. So there is a reason, I'm not just trying to be difficult.

Most of your points are really about the modeller, so would be better placed in the other thread.

Anyway, thanks for the feedback, I can answer a couple of things.

Quote from Snoop.DriftEra :

1. Add: REDO UNDO!!!! For selected items and other actions in other work spaces (Too annoying to not have this).

Redo is quite a lot more difficult from a programming point of view, as the editor wasn't designed in such a way to support that from the outset.

Quote from Snoop.DriftEra :

4. Fix: Texture page 1 pixel bug. Please fix. (it's the whole LFS bug, e.g. XRT's rear seat texture center white stripe).

I don't think this is a bug, if you are talking about the blending from nearby pixels. It's more the atrist's responsibility to ensure that the cutout doesn't butt right up against pixels that are a different colour. It's fundamental to how bilinear filtering works, rather than bad programming.

Quote from Snoop.DriftEra :

5. Add: Ctrl/Shift+RMB values insertion everywhere where values exist including colours.

You can't really just say "do it everywhere". I can't take a few days out from development to examine thousands of buttons to find out which ones don't work as expected. More helpful is specific examples of buttons you find which don't work as expected.

Quote from Snoop.DriftEra :

11. Add: Break from SUBs to SUBs.

Since Editor Test Patch D8, you can now break off triangles from a subobject into a new subobject
> LFS Modeller Suggestions / VladM: https://www.lfs.net/forum/post/1990727#post1990727

Quote from NumberTwo :

IT could be a simple graph instead of clutch pedal graph or it could be something stylized like EV cars have.

Maybe a clutch pedal bar replacement at first, quick and easy to implement (hopefully, if the values can be extracted from the physics system without any trouble). And eventually something for the dashboard display.

Thanks for that overview of some blender functions.

I'm sure we all agree that other work (tyre physics, at the moment) is more important. Still, when a bug is reported I want to fix the bug, then it seems a good time to add one or two long awaited features if they are quick to do.

I don't think LFS editor should try to become a clone of Blender, but we can certainly take a few tips from it and when possible use the same key for a similar function.

Quote from Aleksandr_124rus :

T\N Show up or hide side menus (Modeler kinda have it, will be nice if they can be hide for screenshots or something.

There is SHIFT+F in the modeller which is consistent with hiding the HUD in game.

Quote from ivancsx :

...my suggestion were M for "Fuse to Average", and alt+M for "Fuse to Green" since Shift+M already assigned with "Map" tab, because in Blender ... M were also assigned for fuse (or Merge in Blender menu says)

Or maybe.... can we have a dialog version just like when we tried to extrude points? Would be feel handy with only hotkey M, just like how E for Extrude were defined

A key for fuse/merge points seems to be a popular request. The code is very tiny, so this is really just a decision on keys.

M is already "select main object" so I'm not keen to copy Blender on that. But I understand ALT+M is also the key in blender. That is available in LFS. In blender it brings up a dialog on which type of merge, so we could have "merge to average" and "merge to green" in there if we use a dialog.

Or we could use two shortcuts CTRL+M and ALT+M for merge to average / merge to green. I don't know which way round it should be, or if the dialog popup is better.

I know a lot of people would like to hear more progress.

I've been working on tyre physics but I'm not ready to do a proper report yet.

Just to say for now that a tyre model may be broken into:

- carcass model
- tread model
- friction model

The carcass model is about how the tyre's structure and pressure affect the output forces depending on the state of the wheel. I can use my simulated tyre carcass (non-realtime) to see how some of these forces vary. I've been making changes to the in-game realtime model to more closely match the simulated tyre.

I don't claim that the simulated tyre is an extremely accurate model of a real tyre but it does give an insight into distortion and deflection and how that changes with tyre proportions and pressure.

I'm experimenting, adjusting and thinking a lot so will report some results eventually!

As mentioned in another post, I've had an initial look and made some notes about converting LFS to 64-bit. I don't see any real problems but a lot of lines need to change. Initial thoughts are it might take a week or two, which puts it on a low priority compared with tyre physics. I can't really think of any short-term benefits at the moment other than allegedly it's the only way to connect to OpenXR (which I've barely heard of and obviously would have to code for as well).

Anyway, maybe you could tell me what is the difference or connections between OpenXR and OpenVR and SteamVR?

I thought that the aim of OpenVR was exactly what you seem to be suggesting is the aim of OpenXR. But as far as I know, the only implementation of OpenVR was SteamVR? But thought that didn't have to be the case?

I must say that OpenVR/SteamVR has been really fantastic in providing a way for many games to connect with many headsets. Has its time really come, and why?

I could go reading and researching but thought you might give me a short explanation (if you feel like it).

Quote from superlame :

I assume that, there still be an option in the settings, if we want to see not that much of detailed Shadow, right? ( Don't get me wrong, the shadow looks more than fantastic but, I am bothered about FPS, how will it affect 4 core 2.56ghz cpu ( really specific huh? )

There are some shadow options. Quad core is fine for new LFS as it has two main threads (graphics and physics). That leaves 2 cores for OS use and other minor threads. I think 2.56 GHz should be OK for most things. I've been developing on a dual core CPU with 3.2 GHz (nice fast computer, despite what people seem to think). I imagine you might want to turn down some settings at heavy tracks. But I can't say anything for sure. That might struggle with a full field of visible cars at South City, for example. But my words are pure speculation. We aren't like a big game studio that has actual budgets for such things, it's more like have a go and see what happens, try to optimise what uses a lot of resources.

EDIT: As for shadow options, the biggest one is to switch off shadows in mirrors. But that means very illuminated mirror views if you drive in a dark place. I have on my list to have an option for the number of shadow cascades to be drawn in mirror, Maybe it will not be noticeable to skip the cascade responsible for the distant shadows, for the mirror view.

Also you can set 1024/1536/2048 for the texture resolution per cascade (number of cascades normally 4).

It could be possible to do more optimisations like options to remove smaller objects from the distant cascades. So you still get building shadows but small objects don't produce a shadow which you probably can't see anyway. The trouble with shadow maps is they can draw a lot of things that you can't see and make no difference to anything, but it's hard to stop them doing that in a good way.

Quote from Evolution_R :

Thanks. "A picture is worth a thousand words."

So, I'm on my way to optimize (reduce tris) of the LOD2s of my mods.

I think it always uses the same LOD for the shadow, as for the main object.

But LOD2 is still used to create the soft ambient shadow below the car, even if main object is LOD1.

Last edited by Scawen, Mon, 13 Feb 2023 20:38.

Quote from Facu23 :

new shorcuts works rad. Maybe an extrude one? SHIFT + E or SHIFT + D since they're pretty handy. The save shortcut that eric suggested would be cool too.

I thought about extending CTRL+D (duplicate selected) to other screens like mapping/cutout/page
Also CTRL+N for a NEW point/mapping/cutout/page

I was also thinking about Extrude (that you and r3zp3k7 mentioned) and Flip. I understand people use extrude a lot so SHIFT+E could work for that? Or should it just be plain 'E' ?

Why I say "SHIFT" in this case and not "CTRL": CTRL+key I try to reserve for universal functions that work across the whole of LFS (or many editors in LFS). Operations that are more specific to one particular editor should have SHIFT+key or plain key presses.

About FLIP I wondered if there should be an option to flip the triangles after an extrude, as it's easy to confuse the inside/outside options. If you have points selected (instead of triangles) it could flip the triangles that are connected to the selected points. This way, I think FLIP would work as expected after an extrude. I'm not sure which key to use. F is front view and SHIFT+F hides buttons. Maybe CTRL+F, but that seems like it might have a more system wide use? Any other suggestions for FLIP? What is the key if there is a similar operation in another editor like Blender?

EDIT: Final question for the morning, kenblock30 mentioned a key for "fuse to green". It's another 'F' but F isn't really available for that so thought I'd ask if there is such a function in Blender and which key it uses? Not that we have to copy Blender but it can be a good idea to use the same keys when possible.


P.S. before anyone starts complaining that I am not focussing on tyre physics, I have been working on tyre physics this week and making some progress. But in fact that is a process of doing things and chewing on it a bit, coming up with something to try the next day etc. I can't just work 24-7 on tyre physics. So to do the odd editor function is great for mod creators and can help Eric too.

Last edited by Scawen, Sun, 12 Feb 2023 13:41.

About hotkeys / shortcuts:

Quote from r3zp3k7 :

I suggest adding more hotkeys: like duplicate points/triangles (maybe CTRL+D) and flip triangles (CTRL+F). Makes work way easier, rather than clicking with the mouse every time.

Quote from kenblock30 :

is there any way to add some shortcuts for functions like extrude, duplicate points or fuse to green? It could be really helpful for us who are modeling on the editor

I'm on tyre physics most of the time now but occasionally will update the editor. I wonder what are the most repeated functions (that would most benefit from a special key) and what those keys should be (maybe the same as in another program like Blender, when practical).

I asked Eric in August and he suggested:

Quote from Eric :

As a quick experiment, I've selected a bunch of points in the Modeller and imagined clicking SHIFT+P to select connected triangles/polygons. Clicking SHIFT+P again will select connected points again which works exactly the same as the button function there already. I think that would be useful as P is logical for "polygons" or "points".

He also mentioned CTRL+S to save the main model.

No, it is generated locally. I think the clue is that it is a translated message? Unless it's actually generated by your InSim program? I've looked in the code and can't see anything that would remove a dot from a user name, so was hoping for an easier reproduction.

I'm trying to do things in a simple way, rather than spending a long time creating fake user names, to try to reproduce the fault. This is to save me time as I have a lot of other things to work on. Maybe you could get your friend with a user name that starts with a dot to join a server to create a short MPR.

When i searched our system, I couldn't find a user called ".user1" so assumed it was an example and you are protecting the identity of the user?

A similar thing has happened on the test patch forum. A bug has been reported, I asked for a reproduction, but no-one is interested. That's fine but it'll take me longer to develop the tyre physics if I'm the only one reproducing obscure bugs.

Were all the conditions definitely met? In pit stop, etc. I could stop and test this using two user accounts but I'm in the middle of tyre physics so don't really want to stop at the moment, so if anyone else can test that would be appreciated. I'd suggest testing with D9 and D versions together. If all works then I'd suggest that all is OK.

Last edited by Scawen, Mon, 6 Feb 2023 18:56. Reason : edit: originally wrote D8, meant to say D9

Quote from Facu23 :

lovely option to repair the engine but isn't 12 secs too little for a major engine damage? should be at least 30 or 1 minute.

LFS mechanics are among the world's finest.

Quote from superlame :

Bug report:

You get kicked from 0.7D servers for OOS, when you repair your car on Pit Stops. ( repairing engine damage )

Thank you, now fixed in D8.

Quote from Degats :

The high res physics seems to fix the "dancing" car issue we had on the E-Challenge grid (tested by turning on/off in the replay)

The increased CPU doesn't seem to have much of an effect on my PC, which is nice

It should be a lot better now when tabbing to other cars, often a car would seem to skate off sideways a bit (or a lot) when it hadn't been on the screen for a short while. Partly because it was in low-res physics before you brought it onto screen.

So I hope it might improve the appearance of LFS during the broadcasts quite a bit, along with the D4 update "Reduced glitch of multiplayer cars after TAB or fast forward replay".

All right, thank you for the feedback. D7 is now available.

I went for 97% to distinguish minor / major engine damage. Let's see how that goes.

Changes in D7:

Engine damage can now be repaired in pit stop
- yellow counts as minor damage (6 seconds)
- red counts as major damage (12 seconds)

Engine health now changes from yellow to red at 97%

Engine health percentage is no longer displayed for remote cars

EXPERIMENTAL option to avoid low-res (simple) physics in multiplayer
- Options... Misc... Avoid simple physics [EXPERIMENTAL]
- low res physics is normally applied to cars other than the 4 nearest
- the option approximately doubles CPU usage by physics in multiplayer
- could cause problems at turn 1 with many cars - only use on powerful PC
- use the "profiler" display to check CPU usage with this option enabled
- profiler enabled by pressing car icon then P in Misc or Graphics options

https://www.lfs.net/forum/thread/102117